Deze pagina is vertaald door de Cloud Translation API.

Wat is er nieuw in WebGPU (Chrome 133)
Stay organized with collections Save and categorize content based on your preferences.

François Beaufort

Gepubliceerd: 29 januari 2025

Extra unorm8x4-bgra en 1-component vertex-formaten

Het vertexformaat "unorm8x4-bgra" en de volgende 1-component vertexformaten zijn toegevoegd: "uint8" , "sint8" , "unorm8" , "snorm8" , "uint16" , "sint16" , "unorm16" , "snorm16" en "float16" . Het vertexformaat "unorm8x4-bgra" maakt het iets handiger om BGRA-gecodeerde vertexkleuren te laden met behoud van dezelfde shader. Bovendien kunt u met het 1-component vertexformaat alleen de benodigde gegevens opvragen, terwijl voorheen minstens twee keer zoveel gegevens nodig waren voor 8- en 16-bits gegevenstypen. Zie het artikel in chromestatus en issue 376924407 .

Toestaan dat onbekende limieten worden aangevraagd met een ongedefinieerde waarde

Om de WebGPU API minder kwetsbaar te maken naarmate deze evolueert, kunt u nu onbekende limieten met een undefined waarde opvragen bij het aanvragen van een GPU-apparaat. Dit is bijvoorbeeld handig in de volgende applicatiecode, waar adapter.limits.someLimit undefined kan zijn als someLimit niet meer bestaat. Zie specificatie PR 4781 .

const adapter = await navigator.gpu.requestAdapter();

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

Wijzigingen in de WGSL-uitlijningsregels

Het is niet langer mogelijk om een te kleine uitlijningswaarde voor een structlid op te geven, omdat @align(n) nu vereist is om RequiredAlignOf voor alle structs te delen. Deze ingrijpende wijziging vereenvoudigt het gebruik van de WGSL-taal en maakt deze compatibeler met Firefox en Safari. Voorbeeldcode die de verschillen tussen Tint-, Naga- en WebKit-compilers laat zien, vindt u in de specificatie-PR .

WGSL-prestatiewinst met weggooien

Vanwege een aanzienlijke prestatiedaling bij het renderen van een complex screen-space reflections (SSR)-effect, gebruikt de implementatie van de discard-instructie de door het platform geleverde semantiek om te degraderen naar een helperaanroep, indien beschikbaar. Dit verbetert de prestaties van shaders die discard gebruiken. Zie issue 372714384 .

Gebruik VideoFrame displaySize voor externe texturen

De dimensies displayWidth en displayHeight moeten worden gebruikt als de zichtbare grootte van de GPUExternalTexture bij het importeren van een VideoFrame volgens de WebGPU-specificatie. De zichtbare grootte werd echter onjuist gebruikt, wat problemen veroorzaakte bij het gebruik textureLoad() op een GPUExternalTexture. Dit is nu opgelost. Zie probleem 377574981 .

Verwerk afbeeldingen met niet-standaardoriëntaties met copyExternalImageToTexture

De GPUQueue-methode copyExternalImageToTexture() wordt gebruikt om de inhoud van een afbeelding of canvas naar een textuur te kopiëren. Deze methode verwerkt nu afbeeldingen met een niet-standaardoriëntatie correct. Dit was voorheen niet het geval wanneer de bron een ImageBitmap met imageOrientation "from-image" of een afbeelding met een niet-standaardoriëntatie was. Zie probleem 384858956 .

Verbetering van de ontwikkelaarservaring

Het kan verrassend zijn wanneer adapter.limits hoge waarden weergeeft, maar u zich niet realiseert dat u expliciet een hogere limiet moet aanvragen bij het aanvragen van een GPU-apparaat. Als u dit niet doet, kunnen de limieten later onverwacht worden bereikt.

Om u te helpen, zijn de foutmeldingen uitgebreid met tips die u vragen om expliciet een hogere limiet aan te vragen wanneer er geen limiet is opgegeven in requiredLimits bij het aanroepen van requestDevice() . Zie probleem 42240683 .

In het volgende voorbeeld ziet u een verbeterd foutbericht dat wordt geregistreerd in de DevTools-console wanneer een GPU-buffer wordt gemaakt met een grootte die de standaardlimiet voor de maximale buffergrootte van het apparaat overschrijdt.

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);

⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

Compatibiliteitsmodus inschakelen met featureLevel

Het aanvragen van een GPU-adapter in de experimentele compatibiliteitsmodus is nu mogelijk door de gestandaardiseerde featureLevel optie in te stellen op "compatibility" . De strings "core" (standaard) en "compatibility" zijn de enige toegestane waarden. Zie het volgende voorbeeld en specificatie PR 4897 .

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

De optie featureLevel vervangt de niet-gestandaardiseerde optie compatibilityMode , terwijl het niet-gestandaardiseerde kenmerk featureLevel het kenmerk isCompatibilityMode vervangt.

Omdat het nog experimenteel is, moet je Chrome nu starten met de vlag 'Unsafe WebGPU Support' op chrome://flags/#enable-unsafe-webgpu . Ga naar webgpureport.org om ermee te experimenteren.

Opschonen van experimentele subgroepkenmerken

De verouderde "chromium-experimental-subgroups" en "chromium-experimental-subgroup-uniform-control-flow" zijn verwijderd. Zie probleem 377868468 .

De experimentele functie "subgroups" is nu alles wat u nodig hebt om met subgroepen te experimenteren . De experimentele functie "subgroups-f16" is verouderd en zal binnenkort worden verwijderd. U kunt f16-waarden gebruiken met subgroepen wanneer uw applicatie zowel de functie "shader-f16" als "subgroups" vereist. Zie probleem 380244620 .

Verouder maxInterStageShaderComponents-limiet

De maxInterStageShaderComponents -limiet is verouderd vanwege een combinatie van factoren:

Redundantie met maxInterStageShaderVariables : Deze limiet dient al een soortgelijk doel: het regelen van de hoeveelheid gegevens die tussen shaderfasen wordt doorgegeven.
Kleine verschillen: Hoewel er kleine verschillen zijn in de manier waarop de twee limieten worden berekend, zijn deze verschillen klein en kunnen ze effectief worden beheerd binnen de maxInterStageShaderVariables -limiet.
Vereenvoudiging: Het verwijderen van maxInterStageShaderComponents stroomlijnt de shaderinterface en vermindert de complexiteit voor ontwikkelaars. In plaats van twee afzonderlijke limieten met subtiele verschillen te beheren, kunnen ze zich richten op de meer toepasselijk genaamde en uitgebreide maxInterStageShaderVariables .

Het doel is om het volledig te verwijderen in Chrome 135. Zie het voornemen om het te deprecate en probleem 364338810 .

Dawn-updates

Met wgpu::Device::GetAdapterInfo(adapterInfo) kunt u adaptergegevens rechtstreeks van een wgpu::Device ophalen. Zie probleem 376600838 .

De struct WGPUProgrammableStageDescriptor is hernoemd naar WGPUComputeState om de rekenstatus consistent te maken met de vertex- en fragmentstatus. Zie probleem 379059434 .

De enumwaarde wgpu::VertexStepMode::VertexBufferNotUsed is verwijderd. Een niet-gebruikte vertexbufferlayout kan nu worden uitgedrukt met {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} . Zie issue 383147017 .

Dit behandelt slechts enkele van de belangrijkste hoogtepunten. Bekijk de volledige lijst met commits .